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1.  Background 


This  report  discusses  a  program  that  was  written  in  order  to  support  the  FragFly  model.  The 
FragFly  model  was  created  to  assess  incapacitation  of  human  targets  given  a  detonation  of  a 
fragmenting  munition.  The  model  creates  fragments  using  a  ZDATA  file  (see  “Proposed  Model 
for  Fragmentation  using  ZDATA  Files”); 1  the  fragments  are  flown  out  to  the  surface  of  the 
target,  and  the  model  Operational  Requirements-based  Casualty  Assessment  (ORCA)  is  used  to 
detennine  if  an  incapacitation  has  occurred.  This  is  done  by  supplying  the  ORCA  program 
interface  an  entry  and  exit  location  of  each  fragment  through  the  body  parts.  ORCA  assumes  that 
the  body  and  all  its  parts  have  a  particular  location  and  orientation.  However,  one  of  the 
objectives  of  the  FragFly  model  was  to  allow  the  target  to  be  posed  into  any  posture.  As  a 
compromise,  rigid-body  rotations  of  body  parts  about  joints  are  allowed  to  achieve  intended 
postures.  Rigid-body  rotations  by  definition  have  inverse  rotations.  Therefore,  regardless  of  the 
posture  of  the  body,  entry,  and  exit  points  of  a  fragment  through  the  parts  of  a  postured  body  can 
be  translated  back  into  the  ORCA  reference  frame.  This  overcomes  the  potential  limitations  of 
using  ORCA  to  determine  incapacitation. 

To  do  this  a  multibody  system 2  was  needed  to  properly  represent  the  body  with  moveable  parts 
such  as  arms  and  legs  that  can  be  rotated  around  joints  like  shoulders  and  knees.  A  multibody 
system  is  defined  as  an  assembly  of  two  or  more  rigid  bodies  imperfectly  joined  together,  having 
the  possibility  of  relative  movement  between  them.  Such  a  system  was  created;  however,  it  lacks 
any  kinematic  behavior  traditionally  associated  with  multibody  systems.  A  graphical  user 
interface  (GUI)  tool  was  created  to  provide  users  a  visualization  of  a  body  and  provide  real-time 
feedback  for  posing  the  body  parts. 

This  report  is  broken  down  into  five  main  sections. 

1 .  Section  2.  Introduction  to  the  Multibody  System. 

2.  Section  3.  Input  Files.  This  section  introduces  the  readers  to  the  definitions  of  the  system 
and  how  the  system  is  represented  in  data  files. 

3.  Section  4.  GUI  User  Guide.  This  section  explains  how  to  use  the  GUI  created  to  pose  the 
body. 

4.  Section  5.  Fundamentals  of  Rotations,  Posing,  and  Postures.  This  section  explains  the 
technical  and  mathematical  details  of  the  GUI  and  informs  the  reader  how  the  FragFly 
model  uses  the  output  files  of  the  GUI. 


'  Flanders,  B.  J.  Proposed  Model  for  Finding  Initial  Conditions  of  Fragments  from  a  Detonated  Munition  Using  a  ZDATA 
File',  U.S.  Anny  Research  Laboratory:  Aberdeen  Proving  Ground,  MD,  to  be  published,  2013. 

2 

“http://mat21.etsii.upm.es/mbs/bookPDFs/Chapter01.pdf  (accessed  May,  2013). 
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5.  Section  6.  Conclusions.  At  this  section  the  reader  should  be  able  to: 


•  Recognize  and  create  the  GUI  input  files. 

•  Launch  (or  start)  the  GUI. 

•  Know  how  to  use  the  interface  in  order  to  manipulate  the  moveable  parts  of  the  target. 

•  Recognize  and  understand  the  output  files  of  the  posing  program  and  how  they  will  be 
used  in  the  FragFly  model. 

•  Understand  the  mathematical  expression  used  to  perform  the  manipulations. 

2.  Introduction  to  the  Multibody  System 


There  is  quite  an  extensive  body  of  work  related  to  multibody  systems,  which  has  application  in 
the  gaming  industry,  computer  simulations,  and  robotics  to  name  a  few  domains.  A  rather  simple 
system  was  created  to  capture  core  functionality  that  is  needed  for  the  FragFly  model.  There  are 
four  major  tasks  of  the  system  (which  are  implemented  in  the  GUI). 

1.  Read  input  files. 

2.  Visualize  the  body. 

3.  Manipulate  the  moveable  parts  of  the  body  (called  posing)  with  real-time  feedback. 

4.  Allow  user  to  “commit”  a  posture  by  writing  the  output  files. 

These  tasks  can  be  seen  in  figure  1  as  they  are  implemented  in  the  GUI. 
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Figure  1.  Multibody  system  framework. 

The  input  files  are  shown  on  the  left.  These  files  are  read  in  by  the  GUI  program  and  stored  into 
local  memory.  It  also  creates  two  more  data  structures  called  the  Translation  and  Rotation 
matrices.  They  begin  within  local  memory  and  are  the  only  pieces  of  data  that  are  changed 
throughout  the  lifetime  of  the  GUI.  The  GUI  provides  the  user  a  visualization  of  the  body 
(“Visualize”)  and  user  interface  buttons  to  rotate  the  parts  of  the  body  about  the  joints 
(“Manipulate  Body”).  Notice  the  double  arrow  between  the  functions.  This  means  that  as  the 
body  is  being  manipulated,  the  visualization  of  the  body  is  updated  along  with  the  Translation 
and  Rotation  matrices.  The  process  ends  with  the  user  electing  to  “commit”  a  posture  (i.e.,  the 
visual  orientation  of  the  parts  of  the  body),  which  causes  the  GUI  program  to  write  out  the 
Translation  and  Rotation  matrices.  These  output  files,  along  with  the  Vertex,  Face,  and  Joint 
Location  matrices  become  inputs  for  the  FragFly  model.  Note  that  at  no  point  does  the  GUI 
program  change  the  Vertex,  Face,  or  Joint  Location  matrices. 


3.  Input  Files 


Collectively  the  input  files,  and  the  data  they  contain,  represent  the  user’s  full  understanding  of 
the  body  within  the  system.  It  is  expected  that  many  users  will  not  have  all  the  files  needed  prior 
to  reading  this  report.  However,  by  the  end  of  this  section,  the  reader  should  be  able  to  recognize 
how  to  create  any  missing  input  files. 
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The  data  in  the  system  can  be  categorized  into  two  types:  declarative  and  relational.  Declarative 
data  represents  values  that  can  be  measured  or  quantified.  One  example  of  this  is  a  location  or 
“point”  in  Euclidean  space.  Relational  data  represent  mathematical  functions  or  relations,  which 
cannot  be  replicated  using  standard  mathematical  functions. 

Below  is  a  complete  list  of  the  input  files  separated  by  their  type. 

1 .  Declarative 

a.  Vertex  Matrix 

b.  Joint  Location  Matrix 

c.  Translation  Matrix 

d.  Rotation  Matrix 

2.  Relational 

a.  Face  Matrix 

b.  Joint  Tree  Relation 

c.  Component-joint  function 
Each  of  the  files  will  now  be  discussed. 

3,1  Declarative  Data 

Following  is  a  list  of  the  input  files  that  contain  nonrelational  data.  A  brief  description  of  the  file 
is  given,  along  with  suggested  file  names  in  parentheses.  These  names  will  also  be  used  later 
when  displaying  code  snippets.  In  general,  files  should  not  contain  any  headers  or  text  (except 
for  delimiters),  are  required  to  be  comma  separated,  and  use  “newline”  characters  to  separate 
rows  of  infonnation. 

1 .  Vertex  Matrix  (“vertices.txt”) — lists  the  points  that  lay  on  the  surface  of  each 

subcomponent.  It  is  assumed  that  all  the  vertices  of  the  body  are  stored  in  one  file,  called 
the  vertex  file.  For  a  body  comprised  of  a  total  of  n  vertices,  the  file  will  have  n  lines  and 
have  (at  least)  four  comma-separated  columns.  Additional  columns  will  be  ignored.  The 
first  three  columns  of  a  row  are  the  x,  y,  z  coordinates  of  a  vertex,  respectively,  and  the 
fourth  column  is  the  identification  number  (ID)  of  the  component  (a  more  general  tenn  for 
body  part)  the  vertex  belongs  to.  Figure  2  shows  a  snippet  of  a  vertices  file  with  the 
columns  labeled. 
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Figure  2.  File  description  for  the  Vertex  Matrix  file  (“verts.txt”). 


2.  Joint  Locations  Matrix  (“joints.txt”) — lists  the  location  of  each  joint.  For  a  body  with  j 
joints,  the  joint  location  file  will  have  j  rows  and  three  columns.  The  three  columns  are  the 
x,y,  z  coordinates  of  each  joint,  respectively.  Figure  3  shows  a  snippet  of  a  joint  location 
file  with  the  columns  labeled.  The  order  that  the  joints  are  listed  is  important  because  it 
imposes  on  each  joint  an  ID  number.  The  ID  numbers  will  be  referenced  in  the  relational 
data. 


Figure  3.  File  description  for  the  Joint  Location  Matrix  (“joint.txt”). 

3.  Translation  Matrix  (“translations.txt”) — lists  all  the  global  translation  for  each  joint. 
Essentially,  each  joint  is  assigned  a  translation  vector,  which  initially  has  all  zero  entries. 
As  the  joint  is  relocated,  the  translation  vector  for  the  joint  is  updated  to  reflect  the  change 
in  location  from  the  original  location.  All  the  translation  vectors  are  collected  into  one 
matrix.  For  a  body  with  j  joints,  the  translation  matrix  will  have  j  rows.  The  7th  row  of  the 
translation  matrix  will  correspond  to  the  7th  joint  in  the  Joint  Location  Matrix.  The 
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Translation  Matrix  is  first  created  in  the  local  memory  of  the  GUI  program  and  is  written 
out  when  the  user  “commits”  a  posture.  Again,  for  a  body  with  /joints,  the  file  will  consist 
of  j  rows  and  three  columns.  The  three  columns  represent  the  x,  y,  z  components  of  each 
translation,  respectively.  Figure  4  shows  a  snippet  of  the  Translation  Matrix  as  it  would 
appear  if  it  were  written  out  at  initialization. 


Figure  4.  File  description  of  the  Translation  Matrix  (“translation.txt”). 


4.  Rotation  Matrix  (“rotations.txt”) — lists  the  coordinate  system  matrix  for  each  joint.  This 
matrix  is  first  created  in  the  local  memory  of  the  GUI  program  and  is  written  out  when  the 
user  “commits”  a  posture.  Initially  each  joint  is  assigned  the  three-dimensional  identity 
matrix  as  its  rotation  matrix.  In  order  to  store  all  the  matrices  for  all  the  joints  together, 
each  matrix  is  “vectorized.”  Vectorizing  is  a  process  of  reshaping  a  two-dimensional 
matrix  into  one  dimension.  A  vectorized  matrix  is  one  that  lists  all  the  elements  of  the 
matrix  along  one  row  such  as: 


1  2 
4  5 
.7  8 


[1  2  3  4  5  6  7  8  9], 


(1) 


Figure  5  shows  a  snippet  of  what  the  Rotation  Matrix  file  would  look  like  if  it  were  written  out 
during  initialization. 


6 


To  provide  a  visualization  of  some  of  the  declarative  data,  figure  6  shows  the  human  body  used 
in  the  FragFly  model  (see  “An  Alternative  Representation  of  a  Simulated  Human  Body”).3  Each 
component  and  joint  is  labeled  and  table  1  provides  a  description  for  each. 


Flanders,  B.  J.  An  Alternative  Representation  of  a  Simulated  Human  Body,  U.S.  Army  Research  Laboratory:  Aberdeen  Proving 
Ground,  MD,  to  be  published,  2013. 
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Table  1.  Description  of  subcomponents  and  joints  by  ID. 


Component 

Joint 

ID 

Description 

ID 

Description 

1 

Lower  head 

1 

Neck 

2 

Thorax 

2 

Pelvic 

3 

Abdomen 

3 

Right  shoulder 

4 

Pelvis 

4 

Left  shoulder 

5 

Upper  right  arm 

5 

Right  elbow 

6 

Lower  right  arm 

6 

Left  elbow 

7 

Upper  left  arm 

7 

Left  hip 

8 

Lower  left  arm 

8 

Right  hip 

9 

Upper  right  leg 

9 

Left  knee 

10 

Lower  right  leg 

10 

Right  knee 

11 

Upper  left  leg 

11 

Left  ankle 

12 

Lower  left  leg 

12 

Right  ankle 

13 

Right  foot 

13 

Thoracic  vertebra  2 

14 

Left  foot 

14 

Thoracic  vertebra  10 

15 

Neck 

— 

— 

16 

Upper  head 

— 

— 

3.2  Relational  Data 

Following  is  a  list  of  the  input  files  that  contain  relational  data. 

1 .  Face  Matrix  (“faces.txt”) — used  to  connect  vertices  together  to  form  surfaces  of  the  target. 
For  a  body  with  a  total  of  k  faces,  the  face  file  has  k  rows  and  (at  least)  four  columns.  The 
first  three  columns  of  a  row  in  the  face  matrix  identify  the  three  vertices  that  fonn  a 
triangle  surface  by  their  row  number  in  the  Vertex  Matrix.  The  fourth  column  represents 
the  component  identification  number  that  denotes  assignment.  For  instance,  if  a  row  in  the 
face  file  reads  [1,  17,  28,  5],  then  this  face  is  fonned  by  connecting  the  first,  seventeenth, 
and  twenty-eighth  vertices  found  in  the  Vertex  Matrix  into  one  triangle.  This  face  belongs 
to  the  component  with  the  ID  of  5.  Figure  7  shows  a  template  of  the  face  file. 

2.  Joint  Tree  Relation  (“joint_tree.txt”) — this  file  represents  the  relationship  that  the  joints 
share  with  each  other.  This  relationship  is  best  described  as  an  ordered  tree  relationship. 
Note  that  a  body  may  contain  any  number  of  root  nodes  as  illustrated  in  figure  6,  which 
shows  the  joint  tree  for  a  body  model  in  figure  8. 
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Upper  Right  Arm 
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Figure  8.  Joint  tree  with  component  leaves. 


10 


There  are  many  ways  to  represent  this  structure  conceptually.  One  is  to  define  a  relation  so  that 


JtreeO-tj')  | 


if  j  oint  j  is  a  child  of  j  oint  i 
otherwise 


(2) 


To  be  more  explicit,  one  can  say  that  Jtreeicj)  is  true  if  and  only  if  the  joint  that  is  located  in  the 
/h  row  in  the  “joints.txt”  matrix  is  a  child  of  the  joint  that  is  located  in  the  z'th  row  of  the  same 
matrix.  This  relation  can  be  expressed  by  fonning,  for  a  body  with  j  joints,  a  square  matrix  that 
has  j  rows  and  columns.  The  entry  of  the  zth  row  and  /h  column  will  be  the  value  of  /tree(i,y)- 
Table  2  shows  the  entire  file.  Just  like  all  other  files,  the  values  are  comma  separated  and  rows 
are  separated  by  a  newline  character. 


Table  2.  Joint  Tree  Relation  Matrix. 


Joint 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

Joint 

1 

1 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

2 

1 

1 

1 

1 

1 

1 

0 

0 

0 

0 

0 

0 

1 

1 

3 

0 

0 

1 

0 

1 

0 

0 

0 

0 

0 

0 

0 

0 

0 

4 

0 

0 

0 

1 

0 

1 

0 

0 

0 

0 

0 

0 

0 

0 

5 

0 

0 

0 

0 

1 

0 

0 

0 

0 

0 

0 

0 

0 

0 

6 

0 

0 

0 

0 

0 

1 

0 

0 

0 

0 

0 

0 

0 

0 

7 

0 

0 

0 

0 

0 

0 

1 

0 

1 

0 

1 

0 

0 

0 

8 

0 

0 

0 

0 

0 

0 

0 

1 

0 

1 

0 

1 

0 

0 

9 

0 

0 

0 

0 

0 

0 

0 

0 

1 

0 

1 

0 

0 

0 

10 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

0 

1 

0 

0 

11 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

0 

0 

0 

12 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

0 

0 

13 

1 

0 

1 

1 

1 

1 

0 

0 

0 

0 

0 

0 

1 

0 

14 

1 

0 
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3.  Component-joint  function  (“comp_function.txt”) — notice  that  in  figure  8  the  components 
described  in  table  1  appear  attached  to  a  joint.  Continuing  the  tree  analogy,  the 
subcomponents  can  be  thought  of  as  the  leaves  on  the  joint  tree.  Leaves  can  only  belong  to 
one  branch,  and  in  the  same  way,  a  subcomponent  can  only  be  attached  to  one  joint.  Thus 
one  can  define  a  function  CJ0int(c )  that  maps  the  set  of  subcomponents  Components  -> 
Joints  so  that 

^7'otnt(c)  —  j  (2) 

if  and  only  if  the  subcomponent  s  is  attached  to  joint  j.  It  is  left  as  an  exercise  to  the  reader  to 
form  the  component  joint  function  for  the  tree  in  figure  8. 
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4.  GUI  User  Guide 


Once  the  user  has  correctly  created  all  the  input  files,  he  is  then  ready  to  use  the  GUI.  The  GUI 
program  was  written  in  MATLAB.  The  language  was  chosen  because  of  its  three  dimensionally 
graphing  and  viewing  capabilities.  The  GUI  program  is  a  collection  of  data  files  and  MATLAB 
scripts.  All  the  files  and  scripts  should  be  collocated  in  one  file  directory  for  convenience  (this 
avoids  the  user  from  being  required  to  specify  file  paths).  The  MATLAB  current  directory 
should  be  set  to  the  file  directory  containing  all  the  files. 

There  are  three  actions  that  a  user  can  perfonn: 

1 .  START :  this  will  launch  the  GUI. 

2.  POSE:  control  mechanisms  allow  the  user  to  pose  the  object. 

3.  COMMIT:  after  posing  is  complete,  the  user  can  write  out  the  posture  files. 

Each  action  will  now  be  discussed  in  detail. 

4.1  START 

Assuming  that  the  files  in  the  previous  section  are  named  accordingly,  then  in  the  “Command 
Window”  type: 

»  pose_body (' verts . txt ' ,  'faces.txt',  'joints.txt',  'joint_tree.txt', 

'comp  function.txt') 

The  order  of  files  is  important.  The  file  names  should  be  in  the  following  order:  Vertex  Matrix, 
Face  Matrix,  Joint  Location  Matrix,  Joint  Tree  Relation,  and  Component- Joint  Function. 

This  will  execute  the  function  called  “pose  body,”  which  will  produce  the  window  as  seen  in 
figure  9. 

The  user  may  prefer  to  maximize  the  window,  which  will  make  the  layout  of  the  window  less 
cluttered. 


MATLAB  is  a  registered  trademark  of  The  MathWorks,  Inc. 
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Figure  9.  Startup  window  for  GUI. 

4.2  POSE 

To  pose  the  body,  follow  the  steps  in  figure  10. 

1 .  Select  a  joint  from  the  drop-down  menu  labeled  “Joint.”  The  selected  joint  will  appear  as  a 
red  dot.  The  axis  of  rotation  will  be  redrawn  on  the  joint  selected  and  all  components  that 
will  be  affected  by  the  joint  rotation  appear  as  more  solid  than  the  unaffected  components. 

2.  Select  an  axis  of  rotation  from  the  drop-down  menu  labeled  “AXOR.”  The  selected  axis 
will  appear  in  bold.  The  three  axes  of  rotation  for  a  joint  will  rotate  along  with  the  joint. 
The  axis  of  rotation  is  actually  taken  from  the  coordinate  system  matrices. 

3.  Modify  the  angle  of  rotation  by  using  the  slider  labeled  “Angle.” 
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1.  Select 
Joint 


2.  Select 
Axis  of 
Rotation 


3.  Change 
Angle  of 
Rotation 


Figure  10.  Steps  to  pose  an  object. 

By  default  the  MATLAB  camera  toolbar  is  opened.  This  allows  the  user  to  manipulate  the  view 
of  the  target  to  a  desired  point  of  view.  Camera  actions  do  not  pose  the  object  or  affect  the 
posture. 

4.3  COMMIT 

After  the  body  is  in  a  desired  posture,  the  user  can  “commit”  the  posture  by  pressing  the 
“Commit”  button.  As  mentioned  before,  pressing  this  button  will  write  out  the  Translation  and 
Rotation  matrices  into  files.  Before  the  files  are  written  out  an  adjustment  is  made  to  the 
translation  vectors.  The  adjustment  is  to  ensure  that  the  lowest  point  on  the  body  (the  vertex  with 
the  least  z  component  value)  is  incident  with  the  x-y  plane.  The  user  will  be  prompted  to  provide 
file  names  for  each  posture  file.  Default  values  are  given.  These  files  are  ready  to  be  used  in  the 
FragFly  model. 
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5.  Fundamentals  of  Rotations,  Posing,  and  Postures 

Rotating  a  body  part  about  a  joint  (called  a  joint  rotation)  is  a  multistep  process.  In  a  joint 
rotation  one  must  be  able  detennine  which  components  and  joints  will  be  affected.  For  instance  a 
shoulder  rotation  will  rotate  the  entire  ann  as  well  as  the  elbow  joint.  If  a  joint  is  rotated,  its 
translation  vector  and  rotation  matrix  must  be  updated  in  the  Translation  and  Rotation  matrices, 
respectively.  Before  the  joint  rotation  algorithm  is  discussed,  three  key  concepts  will  be 
presented: 

1 .  Rotate  a  point  about  the  origin 

2.  Rotating  a  point  about  another  point  given  a  rotation  matrix 

3.  Rotate  a  joint’s  rotation  matrix. 

These  concepts  will  help  support  three  main  algorithms: 

4.  Posing  Algorithm 

5.  Posture  Algorithm 

6.  Reverse-Posture  Algorithm. 

5.1  Rotate  a  Point  About  the  Origin 

The  simplest  rotation  is  one  about  the  origin.  Rotations  about  the  origin  are  defined  by  an  axis  of 
rotation  (required  to  be  a  unit  vector),  call  it  u,  and  an  angle  of  rotation,  call  it  9.  The  vector  u 
and  angle  9  can  be  used  to  form  a  matrix  R, 

cos  9  +ux  ■  d  ux  ■  uy  ■  d  —  uz  ■  sin  9  ux  ■  uz  ■  d  +  uy  ■  sin  9 
R  =  f(u,  9)  —  ux  ■  uy  ■  d  +  uz  ■  sin  9  cos  9  +  uy  ■  d  uy  •  uz  •  d  —  ux  ■  sin  9  (4) 

ux  ■  uz  ■  d  —  uy  ■  sin  9  uy  ■  uz  ■  d  +  ux  ■  sin  9  cos  9  +  itf  ■  d 

where  (wx,  uy,  uz)  =  u  and  d  is  (1  —  cos  9).  The  matrix  R  is  matrix  for  of  the  Rodriguez  rotation 
formula.4  It  can  be  used  to  rotate  a  point,  v,  such  that  the  rotated  point,  v',  is 

v'  —  Rv.  (5) 

This  is  represented  in  figure  11,  where  9  is  assumed  to  be  positive. 

^Mason,  M.  T.  Mechanics  of  Robotic  Manipulation ,  Massachusetts  Institute  of  Technology:  The  MIT  Press,  Cambridge,  MA; 
Chapter  3,  figure  3.26,  2001;  46. 
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Of  course,  the  rotation  of  a  point  can  also  be  expressed  as  a  translation,  call  it  t.  Thus,  if 

t  —  Rv  —  v, 


then  v'  can  be  defined  as 


(6) 


v'  =  v  +  t.  (7) 

5.2  Rotate  a  Point  About  Another  Point  Given  a  Rotation  Matrix 

Assume  that  one  wanted  to  rotate  about  a  point  p  instead  of  the  origin.  This  requires  two 
translations.  The  point  v  is  translated  first  by  p,  effectively  making p  the  origin.  That  point  is 
rotated  according  to  rotation  matrix  R.  Finally,  the  rotated  point  is  placed  back  into  the  original 
reference  frame  (a  second  translation  of p).  Thus  t  is  defined  as 

t  =  R(y  —  p)  +  p  —  v.  (8) 

This  translation  can  then  be  applied  to  v  as  in  equation  7. 

Recall  from  section  3.1  Declarative  Data,  that  the  each  joint  is  assigned  a  global  translation 
vector.  It  begins  with  all  zero  entries.  Every  time  t  in  equation  8  is  calculated  for  a  joint,  we  add 
it  to  its  global  translation  vector.  Thus,  one  can  say  that  for  n  poses  that  affect  joint  j,  then 

Tj  =  ^tU],  (9) 

where  7}  is  the  global  translation  vector  for  joint  j. 
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5.3  Rotate  a  Joint’s  Rotation  Matrix 

When  a  joint  is  rotated  about  another  joint,  its  location  may  change.  Regardless  though,  its 
rotation  matrix  will  change.  As  discussed  in  section  3.1,  number  2.,  each  joint  is  assigned  a 
rotation  matrix.  Assume  that  its  rotation  matrix  is  A.  Then  A  is  updated  (symbolized  by  >”) 
such  that 

A  -»  RA  (10) 

for  a  rotation  matrix  R,  defined  in  section  4. 1 . 

Similar  to  equation  9,  after  a  sequence  n  poses  (that  affect  joint  j),  the  rotation  matrix  for  joint  j 
(represented  as  Aj)  will  be 

a^WURuj.  (ii) 

5.3.1  Posing  Algorithm 

We  are  ready  to  define  a  joint  rotation  (or  posing)  algorithm.  First  the  following  is  defined: 

•  “joints” — the  number  of  joints  in  the  body 

•  “comps” — the  number  of  components  in  the  body 

•  “verts(c)” — the  number  of  vertices  in  a  component  for  a  component  with  ID  c 

•  “v(vx)” — the  three-dimensional  location  of  vertex  vx 

•  “p(j)” — the  three-dimensional  location  of  joint  j 

•  ‘y(u,  0)” — a  function  that  returns  the  rotation  matrix  defined  by  u  and  9;  see  equation  4. 

•  “7(a)” — a  function  that  returns  the  global  translation  vector  for  joint  with  ID  a 

•  “i4(a)” — a  function  that  returns  the  rotation  matrix  for  joint  with  ID  a 

•  “*” — matrix  multiplication 

•  Cjointi0 )  an(l  Jtree(i-J)  as  previously  defined 
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The  algorithm  Pose  is  defined  for  the  selection  of  a  joint  (/'),  an  axis  of  rotation  (u),  and  an  angle 
of  rotation  (9)  as  (line  numbers  are  provided  in  brackets  and  “//”  indicates  commented  lines): 

[  1]  Pose  ( j  ,  u,  0)  { 

[2]  R  =  f  (u,  0)  //  Rotation  matrix  calculated 

[  3]  for  (a  =  1: joints) { 

[  4]  if  ( J tree  ( j  ,  a )  ==  1)  { 

[  5]  //  Translate  affected  joint 

[6]  t  =  R*  (p  (a)  -  p  ( j  )  )  +  p  ( j  )  -  p  (a) 

[7]  p  (a)  ->  p  (a)  +  t 

[8]  //  Add  t  to  T 

[9]  T  (a)  ->  T  (a)  +  t 

[10]  //  Rotate  coordinate  system  of  affected  joint 

[11]  A  (a)  -»  R*A  (a) 

[12]  //  Check  if  a  subcomponent  is  attached  to  the  joint 

[13]  //  If  so,  rotate  the  subcomponent 

[14]  for  (c  =  1 : comps ){ 

[15]  if  (Cjoint  (c)  ==  a)  { 

[16]  for  (vx  =  l:verts(c){ 

[17]  t  =  R (v (vx)  -  p(j))  +  p(j)  -  v (vx) 

[18]  v  (vx)  ->  v  (vx)  +  t 

[19]  } 

[20]  } 

[21]  ) 

[22]  ) 

[23]  } 

[24]  } 


The  algorithm  first  calculates  the  rotation  matrix  using  the  axis  and  angle  of  rotation.  For  each 
joint  in  the  body  (line  3),  if  the  joint  is  a  child  of  joint  j  (line  4),  then  the  child  joint  is  relocated 
(line  7).  The  child  joint’s  rotation  matrix  and  global  translation  vector  are  also  updated  (lines  9 
and  1 1).  Finally,  whatever  component  affected  (line  15),  all  of  its  vertices  need  to  be  translated 
(line  18). 

Note  that  vertices  are  changed  for  visualization  purposes  only.  The  Vertex  Matrix  file  is  never 
changed  only  its  representation  within  the  physical  memory  of  the  program. 

5.3.2  Transforming  a  Body  Into  a  Posture 

A  posture  is  defined  as  a  terminating  sequence  of  poses.  However,  now  a  more  formal  definition 
can  be  presented.  Notice  that  the  posing  algorithm  updates  the  global  translation  vector  and 
coordinate  system  for  certain  joints  (lines  9  and  1 1  of  the  Pose  algorithm).  Therefore,  a 
terminating  sequence  of  poses  will  produce  final  values  for  the  global  translation  vector  and 
rotation  matrix  for  each  joint.  Thus,  a  posture  is  defined  as  a  set  of  Translation  (T)  and  Rotation 
(A)  matrices. 


P  =  { T,A } 


(12) 
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This  set  represents  a  relatively  small  set  of  data  needed  to  posture  an  object  compared  to 
recording  a  translation  vector  for  each  vertex.  This  is  exactly  how  the  posture  is  defined  in  the 
FragFly  model. 

Similar  to  the  Pose  algorithm,  a  Posture  algorithm  will  be  presented.  The  purpose  of  this 
algorithm  is  to  translate  the  vertices  of  a  body  to  match  the  predetermined  posture  found  in  the 
posture  files.  There  is  no  way  to  load  a  posture  into  the  GUI.  However,  this  would  be  a  very 
simple  update  to  the  GUI.  The  Posture  algorithm  will  only  modify  the  locations  of  the  vertices  in 
the  subcomponents.  Assuming  one  has  access  to  the  posture  P  as  defined  in  section  5.3.1.  Refer 
to  the  Pose  pseudo-code  for  function  definitions. 


[  1 ]  Posture (T, A) { 

[  2]  for  (s  =  1 : subcomponents ) { 

[3]  j  =  C (s) 

[4]  R  =  A  ( j  ) 

[5]  p  =  v(j) 

[  6]  for  (vx  =  l:verts(s){ 

[7]  t  =  R* (vert (vx)  -  p)  +  p  +  T(j) 

[  8]  vert  (vx)  -*  vert  (vx)  +  t 

[  9]  } 

[10]  } 

[11]  } 

[12]  } 


5.3.3  Reverse  Posture  Algorithm 

Assume  that  one  wanted  to  reverse  the  process  of  transforming  a  body  into  a  posture.  In  the 
Posture  algorithm,  only  the  vertices  of  the  appropriate  component  were  translated.  The  reverse 
posture  algorithm  will  add  a  layer  of  abstraction  by  returning  a  translation  vector  based  on  the 
inputs.  The  algorithm  is  defined  this  way  so  that  the  FragFly  model  can  have  a  method  to  map 
the  locations  of  the  entry  and  exit  points  to  a  component  to  the  ORCA  reference  frame. 

The  reverse  posture  algorithm,  call  it  “ Unposture ,”  has  three  input  arguments: 

1 .  v  — three-dimensional  point 

2.  c  — a  subcomponent  ID  that  p  is  associated  with 

3 .  P  — the  posture  set 

The  Unposture  algorithm  returns  one  value  t,  which  is  a  translation  vector.  This  represents  the 
translation  of  the  point  v  to  move  it  to  the  original  orientation  of  the  body  part  with  ID  c. 
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The  following  functions  and  variables  will  be  used  in  the  pseudo-code: 


•  — a  function  that  returns  the  global  translation  vector  for  the  joint  with  ID  j 

•  “P(A  /)” — a  function  that  returns  the  coordinate  system  for  the  joint  with  ID  j 

•  “( A)t  ” — a  unary  operator  that  transposes  the  matrix  A 

•  *' 'joint(j )” — a  function  that  provides  the  location  of  the  joint  with  ID  j 


The  algorithm  Unposture  thus  defined  as: 


[  1] 

t  =  Unpose  (v,  c,  P)  { 

[  2] 

j  =  Js(s) 

[  3] 

t  =  ( P  (A,  j  )  )  T*  ( v  -  (joint(j)  +  P  (T,  j  )  ) 

)  +  joint(j)  -  v 

[  4] 

return  t 

The  justification  of  this  algorithm  is  left  to  the  reader. 


6.  Conclusions 


The  FragFly  model  requires  that  users  provide  a  number  of  input  files  associated  with  the  human 
target.  These  files  are  part  of  a  multibody  system  that  was  created  that  allows  a  body  constructed 
of  moveable  parts  to  be  manipulated.  A  GUI  was  created  that  simplifies  the  task  of  manipulating 
the  body  and  provides  real-time  feedback.  The  details  of  the  operations  within  the  GUI  were 
discussed,  as  well  as  the  role  the  output  files  for  the  GUI  play  in  the  FragFly  model. 

The  following  are  suggestions  for  future  development: 

1 .  Cosmetic  changes  to  the  GUI  to  promote  ease  of  use. 

2.  Allow  users  to  load  postures  into  the  GUI  from  posture  files. 

3.  Include  an  “undo”  button  to  take  back  the  last  set  of  changes  for  a  body  part. 
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Appendix  A.  “posebody.m” 


This  appendix  appears  in  its  original  form,  without  editorial  change. 


function  pose_body (v_f ile,  f_file,  joints  file,  j2j_file,  j2c_file) 

%  Load  data 

v  =  dlmread (v  file, 1 ,  ' ) ; 
f  =  dlmread (f_file, ',') ; 
p2p  =  dlmread  (j2j_file, ',')  ; 
p2c  =  dlmread (j2c_file, ; 
leafj  =  p2c(end,  :); 
p2c  (end,  : )  =  [  ]  ; 

joints  =  dlmread ( joints_file,  ; 
org_j  =  joints; 

jR  =  repmat([l  0  0  0  1  0  0  0  1]  ,  size  (p2p,  1)  ,  1)  ; 
axor  =  repmat([l  0  0  0  1  0  0  0  1] , size  (p2p, 1) , 1) ; 
thetas  =  zeros (14,3) ; 
cameratoolbar; 

%hax  =  axes (' Parent ', hfig) ; 
j  =  1 ;  ax  =  1 ;  theta  =  0 ; 

%%%%%%%%%%%%%%%%%%  Slider 

angle_text  =  uicontrol ( ' Style ' , ' text ' , . . . 

'String ' Angle :  O',  'Position' ,[20  60  100  20]); 
slider  =  uicontrol (' Style ' ,  'slider',... 

'Min ' , -180, 'Max ' , 180, 'Value ' , 0, . . . 

'Position',  [20  40  300  20 ],' SliderStep ',[ 1/360  10/360],... 

' Callback ' ,  { @slider_callback, angle_text } ) ; 

uicontrol (' Style ',' text ',' String ',[' -150  -100  -50 

'  50  100  150  '],  'Position' , [20  0  300  20]) 

uicontrol ( ' Style ' , ' text ' , ' String ' , [ ' 

'  I  I  I  I  I 

'Position' , [20  20  300  20]); 

set (slider , 1  User Data ' , (joints, axor, jR, leafj, p2p,j, ax, org_j , v, f , . . 

theta, p2c, thetas } ) ; 
graph_stuff (slider) ; 

legend ( { ' Target '  ,  'Joints',  ' Selected  Joint '  ,  'Pitch '  ,  ' Roll ' ,  ' Yaw ' } , 
' Location ' , ' NorthOutside ' ) 
daspect ( [ 1  1  1 ] ) ; 

%%%%%%%%%%%%%%%%%%  Joint  list 
j_text  =  uicontrol ( ' Style ' ,  ' text '  ,  .  .  . 

' String ',' Joint :' ,  ' Position ',[ 20  160  40  20]); 

jlist  =  uicontrol (' Style '  ,  'popup',... 

'String',  '1|2|3|4|5|6|7|8|9|10|11|12|13|14',... 
'Position',  [20  110  40  50],... 

'Callback',  ( @ j list_callback,  slider}); 


ax_text  =  uicontrol ( ' Style ' , ' text ' , . . . 

' String' , 'AXOR; ' ,  ' Position ', [20  110  40  20]); 
axlist  =  uicontrol (' Style ' ,  'popup',... 

' String ' ,  ' Pitch | Roll  I  Yaw ' ,  .  .  . 

'Position',  [20  60  80  50],... 

' Callback ' ,  { @ax_callback, slider} ) ; 

%%%%%%%%%%%%%%%%%%  Commit  Button 

comm_pb  =  uicontrol  ( '  Style  '  ,  '  pushbutton  '  ,  .  .  . 

' Position ',[ 12 0  110  100  40],  'String',  ' Commit ',' Callback ',. . 
{ @commit_callback, slider} )  ; 
axis ( [-1  1  -1  1  0  2.2] ) 
set  (gca,  'view ',[ 158 . 0000  13]); 


end 

%%%%%%%%%%%%%%%%%%% 


SUBROUTINES  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 


function  slider_callback (hOb j ,  eventdata, 
ud  =  get (hObj , ' UserData ' ) ; 
joints  =  cell2mat (ud (1) )  , 
axor  =  cell2mat (ud (2) ) 
jR  =  cell2mat  (ud  (3)  ) 

leafj  =  cell2mat  (ud  (4)  ) 
p2p=  cell2mat (ud (5) ) 

j  =  cell2mat (ud (6) ) 

ax  =  cell2mat (ud (7) ) 

org_j  =  cell2mat (ud (8) )  , 
v=  cell2mat (ud (9) ) ; 

f=  cell2mat (ud(10) ) ; 

thetas  =  cell2mat (ud (13) ) ; 


anglhand) 
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%  set (hObj , 'Value' , thetas (j ))  ; 

angle  =  round (get (hObj , 'Value ')) -thetas (j , ax) ; 
thetas (j, ax)  =  round (get (hObj , 'Value ')) ; 
p2c  =  cell2mat (ud (12) ) ; 
theta  =  thetas  (j  ,  ax)  ; 

[joints,  axor,  jR,  R] =TRT (j , ax, angle, j oints , axor , p2p, jR) ; 
trans  =  joints; 

%  Apply  each  translation  and  rotation  to  each  component 
for  vr  =  l:size(v,l) 

if  (p2c  (j  ,  v  (vr,  4)  )  ==  1) 

v(vr,l:3)  =  (R*  (v  (vr,  1 :  3)  -  trans  (j,:))'  +  trans  (j  ,:)')' ; 

end 

end 

set (hObj ,  ' User Data  1 , {joints, axor, jR, leaf j ,p2p, j , ax, org_j , v, f , 0, . . . 
p2c, thetas } ) ; 

set (anglhand,  'String ' ,  [ ' Angle ;  1  ,  .  .  . 

num2str (round (get (hObj , 'Value ')))]); 
graph_stuf f (hObj ) ; 

end 

function  j list_callback (hob j ,  eventdata,  shand) 
j=  get (hObj , 'Value ') ; 
ud  =  get (shand, ' UserData ') ; 

ud(6)  =  num2cell(j);  thetas  =  cell2mat (ud ( 13) ) ; ax  =  ud{7}; 
cla;  hold  on; 

joints  =  cell2mat (ud ( 1 ) ) ; v=cell2mat (ud (9) ) ;  f  =  cell2mat (ud ( 10) ) ; 

set (shand,  'UserData',  ud)  ; 

set (shand,  'Value ' , thetas ( j , ax) ) ; 

graph_stuff (shand) ; 

end 

function  ax_callback (hob j ,  eventdata,  shand) 
x=  get (hOb j , ' Value ' ) ; 
ud  =  get (shand, ' UserData ') ; 
ud (7 ) =num2cell (x) ;  j=ud{6}; 
set (shand,  'UserData',  ud)  ; 
thetas  =  cell2mat (ud (13) ) ; 
set (shand,  'Value ' , thetas ( j , x) ) ; 
graph_stuff (shand)  ; 

end 

function  commit_callback (hObj , eventdata,  shand) 
ud  =  get (shand, ' UserData ')  ; 
jR  =  cell2mat (ud (3) ) ; 

%  C++  conversion 
for  j  =  l:size(jR,l) 

j  R  ( j  ,  : )  =  reshape  (reshape  (jR  (j  ,:),  3, 3)  ',  1 , 9)  ; 

end 

trans  =  cell2mat (ud (1 ) ) -cell2mat (ud (8) )  ; 
v  =  cell2mat(ud(9)); 

trans(:,3)  =  trans(:,3)  -  min(v(:,3)); 

rot_file  =  uiputfile (' rotations . txt ',' Save  Rotation  Matrices'); 
if  (rot_file  ~=  0) 

dlmwrite (rot_file, jR, ' delimiter newline ' , 'pc ' ) ; 

end 

trans_file  =  uiputfile (' translations . txt ',' Save  Translation  Matrix'); 
if  (trans_file  ~=  0) 

dlmwrite (trans_f ile, trans , ' delimiter newline ' , ' pc ' ) ; 

end 

try 

%  Using  the  rotate_human  tool 

sv  =  dlmread ( 'verts . txt ',',')  ; 

sf  =  dlmread (' faces . txt ',',') ; 

jR  =  dlmread (rot_file,  '  ,  ' )  ; 

trans  =  dlmread (trans_f ile, ' , ' ) ; 

joints  =  dlmread (' joints . txt ',',') ; 

leaf j  =  [1,13,14,2,3,5,4,6,8,10,7,9,12,11,13,1]; 

for  svr  =  l:size(sv,l) 

lfc  =  leaf j (sv (svr, 4 ) ) ; 

R  =  reshape  (jR(lfc,  : )  ,3,3)  '  ; 
sv (svr, 1:3)  =  ... 

(R* (sv (svr, 1 : 3) -joints (lfc, :)) ' +j oints (lfc, :) ') ' +trans (lfc, : ) 

end 

cla;  hold  on; 
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patch ( ' vertices ',sv(:,l:3), 'faces',sf(:,l:3)+l, ' facealpha ' ,1 . 

' edgealpha ',0.005, 'facecolor', ' g ' , ' f acelighting ' , ' phong ' ) ; 
daspect ( [ 1  1  1 ] ) 
catch 

errordlg (' Could  not  find  files  or  you  cancelled  while  creating  files.'); 

end 

end 

function  graph_stuff (slider) 
cla;  hold  on; 

ud  =  get (slider, ' UserData ') ; 

%  Graph  patches 

v=cell2mat (ud (9) ) ;  f=cell2mat (ud (10) ) ; 

patch ( 'vertices '  ,v (:,  1 : 3)  ,  ' faces '  ,  f ( : ,  1 : 3) +1,  ' facealpha '  ,  . 05,  . . . 

' edgealpha ',0.05, 'facecolor', 'g', ' facelighting ' , ' phong ' ) ; 

%  Graph  joints 

joints  =  cell2mat (ud (1) ) ; 

scatter 3 ( joints (:, 1) , joints (:, 2) , joints (:, 3) , 'bo', 'filled'); 
j  =  ud{ 6 } ; 

scatter  3  (joints(j,l),joints(j,2),joints(j,3),  '  ro  '  ,  'filled'); 

%  Add  text  labels 
of st  =  .04; 

for  j  j=l :  size  (joints,  1 ) 

text  (joints  (jj,  1)  +of  st,  joints  (jj,  2)  +of  st,  joints  ( j  j  ,  3)  +of  st,  .  .  . 
num2str ( j  j ) ,  ' Font Size ' , 10 ) ; 

end 

jR  =  cell2mat (ud (3) ) ; 
scl  =  .4; 

%if  (ud{  7 }  ==1) 

plot3([joints(j,l)  joint s(j,l)+jR(j,l)*scl],  .  .  . 

[  joints  (j  ,  2)  joints  ( j  ,  2)  +  jR  ( j  ,  2)  *scl]  ,  .  .  . 

[  joints  (j  ,3)  joints  (j  ,3)  +jR(j  ,3)  *scl]  ,  '  r-  '  ,  .  .  . 

'Linewidth' , 1+2* (ud{7}==l) ) ; 

%elseif  (ud{ 7 }  ==  2) 

plot3([joints(j,l)  joint s(j,l)+jR(j,4)*scl],  .  .  . 

[  joints  (j  ,  2 )  joints(j,2)+jR(j,5)*scl],  .  .  . 

[  joints  (j  ,  3)  joints(j,3)+jR(j,6)*scl],  'b-  '  ,  .  .  . 

'Linewidth' , 1+2* (ud{7}==2) ) ; 

%else 

plot3([joints(j,l)  joints  ( j  ,  1)  +jR  ( j  ,  7)  *scl]  ,  .  .  . 

[  joints  (j  ,  2)  joint  s(j,2)+jR(j,8)*scl],  .  .  . 

[  joints  (j  ,  3)  joints(j,3)+jR(j,9)*scl],  '  k-  '  ,  .  .  . 

'Linewidth' , 1+2* (ud{7}==3) ) ; 

%end 

joints  =  find  (ud{  1 , 5 }  (ud{  1 , 6 } ,  :  )  )  ; 
for  j=l : size (joints, 2 ) 

comps  =  f ind (ud{ 1 , 4 }==joints ( j ) ) ; 
for  c  =  1 : size (comps , 2 ) 

patch ( ' vertices ' , v ( : , 1 : 3) , 'faces',f(f(:,4) +l==comps (c) , 1 : 3) +1, ' facealpha ' , . 5, . . . 
' edgealpha ',0.1, ' facecolor ' , ' g ' , ' facelighting ' , ' phong ' ) ; 

end 

end 

light 

daspect ( [ 1  1  1 ] ) 

end 
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Appendix  B.  “TRT.m” 


This  appendix  appears  in  its  original  form,  without  editorial  change. 
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function  [pivot,  axor,  jR,  R]  =  TRT(k,  x,  rads,  pivot,  axor,  p2p,  jR) 

%  Find  the  rotation  matrix  R,  and  translate,  rotate,  and  translate  affected  joints 

R  =  zeros (3) ; 

rads=rads* (pi/180)  ; 

c=cos (rads) ; d=l-c; s=sin (rads) ; 

vO=axor (k,  3* (x-1)  +1)  ; 

vl=axor (k, 3* (x-1 ) +2 )  ; 

v2=axor (k, 3*x)  ; 

R ( 1 ) =vO*vO*d+  c  ;  R (4 ) =v0*vl*d-v2*s  ;  R (7) =v0*v2*d+vl*s  ; 

R (2 ) =vl*v0*d+v2*s  ;  R (5) =vl*vl*d+  c  ;  R (8) =vl*v2*d-v0*s  ; 

R (3) =v2*v0*d-vl*s  ;  R ( 6) =v2*vl*d+v0*s  ;  R ( 9) =v2*v2*d+  c  ; 
for  p  =  1 :  size  (p2p, 2 ) 
if  (p2p (k, p)  ==  1) 

%  Transform  affected  pivot  points 

pivot (p, 1:3)  =  (R* (pivot (p, 1 : 3)  -  pivot (k,  :))'  +  pivot (k,  :)')' ; 

%  Transform  affected  axes 
for  jj  =  1:3 

tax  =  R* (axor (p,  (3*  (j j-l)+l)  :3*j j)  )  '  ; 
axor (p,  (3*  ( j j-1) +1)  : 3* j j )  =  tax/norm (tax) ; 

end 

%  The  jR  matrices  are  stored  row-major.  So  we  need  to  transpose 

%  them  in  order  to  multiply  it  by  R 

jR(p, :)  =  reshape ( (R*reshape ( jR (p, : ) , 3, 3) ) , 1, 9) ; 

end 

end 
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